In communication systems consisting of multiple Autonomous Systems (ASs), a routing protocol is required whereby the ASs can share information about sites and hosts that can be reached within each ASs. A common routing protocol, and the routing protocol used in the Internet for Internet Protocol version 4 (IPv4) traffic, is the Border Gateway Protocol version 4 (BGP-4). BGP-4 is defined in Rekhter, Y., and Li, T., “A Border Gateway Protocol 4 (BGP-4)”, IETF RFC1771, T. J. Watson Research Center, cisco, March 1995, incorporated by reference herein. BGP-4 allows Border Gateway Protocol Speakers (BGP Speakers) to automatically and periodically exchange Network Layer Reachability Information (NLRI). NLRI is sent as part of an Update message between border gateways. Each Update message may advertise one feasible route. A feasible route includes a NLRI field, composed of a list of Internet Protocol (IP) addresses which are destinations of the route, and zero or more Path Attributes, which each include an Attribute Flag, an Attribute Type Code and an Attribute Value. BGP-4 defines several Attribute Type Codes, but allows new Attribute Type Codes to be defined. Using NLRI collected over time from Update messages, each BGP Speaker builds routing databases whereby a route to a destination within the communication system can be determined.
Due to the definition of some Attribute Value fields within BGP-4, BGP-4 is capable of carrying routing information only for IPv4 traffic. However some communication systems implement different networking systems. For example, different Open System Interconnect (OSI) layer-2 or layer-3 protocols may be used within the communication system. One solution is proposed in Bates, T., Chandra, R., Katz, D., and Rekhter, Y., “Multiprotocol Extensions for BGP-4”, IETF RFC2283, Cisco Systems, Juniper Networks, February 1998, incorporated by reference herein, in which extensions to BGP-4 are defined. The resulting BGP Multiprotocol Extensions (BGP-MP) enable BGP-4 to distribute routing information for multiple network layer protocols. BGP-MP introduces two new Path Attributes. The first new Path Attribute, Multiprotocol Reachable NLRI (MP_REACH_NLRI), carries a set of destinations reachable through the BGP Speaker which sent the Update message, together with next hop information. The new Attribute Type Code of MP_REACH_NLRI is defined to have a value of “14”. MP_REACH_NLRI is defined as an optional Path Attribute using the Attribute Flag (to allow for backward compatibility). The Attribute Value of MP_REACH_NLRI consists of several fields. The first field in the Attribute Value is an Address Family Identifier field, which identifies the network layer protocol associated with the destinations identified in an NLRI field. The second field in the Attribute Value is a Subsequent Address Family Identifier (SAFI) field, which provides additional information about the type of NLRI carried in the Path Attribute. The second new Path Attribute, Multiprotocol Unreachable NLRI (MP_UNREACH_NLRI) carries a set of routes which are to be withdrawn from the routing database of the BGP Speaker which receives the Update message. The new Attribute Type Code of MP_UNREACH_NLRI is defined to have a value of “15”. Like MP_REACH_NLRI, MP_UNREACH_NLRI is defined as an optional Path Attribute, and its Attribute Value includes an Address Family Identifier field and a SAFI field. In summary, when a BGP Speaker receives an Update message having an Attribute Type Code of “14” or “15”, the BGP Speaker realizes that the destinations listed in the NLRI field are associated with the network layer protocol identified by the Address Family Identifier field.
Network based Virtual Private Networks (VPNs) are emulations of private wide area networks using public or other party backbone facilities. Network based VPNs allow a business to run a wide area network over a large geographic area without having to purchase and manage its own backbone, thereby saving costs. For example, a business may own computers at two geographically separate sites, and wish to connect them as a network. Network based VPNs provide a means for the business to link the two sites using the backbone facilities of someone else (referred to as a provider). Network based VPNs can be implemented using either a piggybacking model (Rosen, E., et al., “BGP/MPLS VPNs”, IETF Internet-Draft update of RFC2547, May 2000, incorporated by reference herein, provides an example of a piggybacking model) or a Virtual Router model (see, for example, Ould-Brahim, H., et al., “Network based IP VPNs using Virtual Routers”, IETF Internet-Draft, July 2000, incorporated by reference herein). Current methods for implementing network based VPNs in either model require the same networking system to be used in each VPN as is used in the backbone. However, when purchasing VPN services from a provider a business with an existing private network may not wish to alter its networking system in order to comply with the networking system used by the backbone and the other VPNS. There is a need for a VPN information distribution scheme which allows different networking systems to be used by each VPN and by the backbone.